在軟體開發中，瀑布式流程（Waterfall Development Process）以其結構化的階段性特點，常被用於需求明確、變更較少的專案。然而，需求的模糊或誤解，往往導致開發過程中的返工和延誤。

這篇將針對三種不同的瀑布式開發情境，說明如何使用實例化需求：

• 大批量循序開發：假設一次處理 100 個功能，需求一次定義完成。
• 分批循序開發：假設總共 100 個功能，每次處理 10 個，分批完成。
• 不定期需求開發：需求隨時進來，每次數量不定。

每種情境會詳細說明方式、步驟、參與角色、工具和注意事項，並搭配一個具體的故事案例，讓你輕鬆理解如何在瀑布式流程中應用。咱們開始吧！

9.1 大批量循序開發

這是最傳統的瀑布式流程，所有功能的需求在項目開始前就全部定義好，需求分析階段一口氣完成，然後依序進入設計、開發、測試和部署。在這種情境下，主要是幫忙把大量需求，轉成具體的範例，確保每個功能都清晰且一致。

(1) 方式

• 集中式需求澄清：組織大型工作坊，把 100 個功能的需求逐一拆解成具體範例。
• 結構化文件：用統一格式（像表格或 Gherkin）記錄所有範例的規格，作為後續階段的參考。
• 分組討論：因為功能數量多，可能分成幾個小組，同時處理不同功能的需求。
• 作為驗收基礎：這些範例會成為測試階段的驗收標準，確保每個功能都符合預期。

(2) 步驟
A. 需求收集：

• 產品負責人提供 100 個功能的初步需求清單，可能是一個大表格或文件。
• 業務分析師整理這些需求，按功能類型分組（例如：用戶管理、支付、報表）。

B. 大型工作坊：

• 召集所有相關角色（產品負責人、業務分析師、開發者、測試者），開一個為期幾天的工作坊。
• 將功能分成小組，每組負責 20-30 個功能，針對每個功能寫出 Given-When-Then 格式的範例。
• 例如，對於「用戶註冊」功能，範例可能是：

Given：用戶輸入有效的 email 和密碼；
When：點擊「註冊」；
Then：系統創建帳戶並發送確認郵件。

C. 精煉與整合：

• 各小組的範例彙整到一個統一的文件中，確保格式一致。
• 涵蓋正常情況、邊界條件和異常情況（例如：無效 email、伺服器錯誤）。
• 產品負責人審查所有範例，確認符合業務需求。

D. 文件化與傳遞：

• 把所有範例寫進需求規格書，可能是一個巨大的 Confluence 頁面或 Excel 表格。
• 設計、開發、測試階段的團隊參考這些範例，確保一致性。

E. 驗證與交付：

• 測試階段用範例作為驗收測試的基礎，逐一驗證 100 個功能。
• 如果發現問題，回溯到需求階段，更新範例並通知相關團隊。

(3) 參與角色

• 產品負責人：提供 100 個功能的需求，審查範例。
• 業務分析師：主持工作坊，整理和整合範例。
• 開發者：參與討論，確保範例技術上可行。
• 測試者：確認範例可以用於驗收測試。
• 專案經理：協調進度，管理大型工作坊。

(4) 工具

• 文件工具：Confluence、Google Docs，記錄大量範例。
• 協作工具：Miro（視覺化討論）、Jira（追蹤功能）。
• 規格工具：Cucumber（Gherkin 格式）、Excel（表格化範例）。
• 測試工具：Selenium、Cucumber，支援自動化驗收測試。

(5) 注意事項

• 避免過載：同時進行所有功能的範例討論，這是很龐大的工作，工作坊要分組並控制進度，否則容易混亂。
• 保持一致性：不同小組的範例格式要統一，否則後續階段會有誤解。
• 涵蓋全面：每個功能都要有正常、邊界和異常場景，否則測試階段會漏掉問題。
• 時間壓力：需求階段可能花幾週，專案經理要確保進度不拖延。
• 變更困難：瀑布式流程不靈活，一旦需求定案，後期變更會很麻煩，範例要盡量寫完整。

(6) 故事案例
假設你是某銀行的專案經理，要開發一個新的線上銀行系統，包含 100 個功能（像是轉帳、查詢餘額、申請貸款等）。需求階段開始，產品負責人給了一份 300 頁的需求文件，但很多地方很模糊，像是「支援多幣種轉帳」沒說清楚細節。

你組織了一個為期 5 天的工作坊，找來產品負責人（小美）、業務分析師（小明）、開發者（小強）、測試者（小花）和 10 位其他相關人員。把 100 個功能分成 5 組，每組負責 20 個功能。第一組負責「轉帳功能」，他們針對「多幣種轉帳」寫了範例：

Given：用戶有 1000 美元的帳戶，選擇轉 500 美元到歐元帳戶，匯率是 1 美元 = 0.85 歐元；When：確認轉帳；
Then：美元帳戶扣 500 美元，歐元帳戶收到 425 歐元。

其他範例包括：無效幣種、餘額不足等。
所有組的範例彙整成一個 Confluence 頁面，總共 300 個場景。小美審查後簽字確認。設計和開發階段參考這些範例，測試階段用它們驗證系統。最後，系統上線時，轉帳功能完全符合預期，客戶滿意，團隊也因為前期澄清省下很多修改時間。

9.2 分批循序開發

這種流程還是瀑布式的，但把所有功能分成批次處理。例如總共有 100個功能，分成10 批處理，每批處理 10 個功能。

每批都完整走一遍需求 → 設計 → 開發 → 測試 → 部署，然後再開始下一批。Spec by Example 在每批的需求階段幫忙把 10 個功能的需求轉成具體範例，保持清晰且可管理。

(1) 方式

• 小規模工作坊：每批只處理 10 個功能，組織小型會議來討論範例。
• 迭代式文件：每批的範例獨立記錄，但保持一致的格式，累積成完整的規格庫。
• 快速反饋：每批結束後，檢討範例寫得如何，改進下一批的做法。
• 測試重用：每批的範例成為驗收測試基礎，後續批次可參考前面的範例。

(2) 步驟
A. 需求收集：

• 產品負責人提供當前批次（10 個功能）的需求清單。
• 業務分析師整理需求，初步分類（例如：支付相關、用戶介面）。

B. 小型工作坊：

• 召集產品負責人、業務分析師、開發者、測試者，開 1-2 天的工作坊。
• 針對 10 個功能，逐一寫出 Given-When-Then 格式的範例。
• 例如，對於「支付確認」功能：

Given：用戶選擇信用卡支付 100 元；
When：點擊「確認支付」；
Then：系統扣款成功並顯示「支付完成」。

C. 精煉範例：

• 確保範例簡單，涵蓋正常、邊界和異常場景（例如：信用卡無效、網路斷線）。
• 產品負責人確認範例符合業務需求。

D. 文件化與傳遞：

• 把這批的範例寫進需求規格書（例如：Jira ticket 或 Confluence 頁面）。
• 設計、開發、測試階段參考這些範例。

E. 驗證與下一批：

• 測試階段用範例作為驗收標準，完成後部署這批功能。
• 檢討這批的 Spec by Example 過程（例如：範例是否夠清楚），改進下一批。

(3) 參與角色

• 產品負責人：提供每批的 10 個功能需求，審查範例。
• 業務分析師：整理需求，主持工作坊，記錄範例。
• 開發者：參與討論，確認範例技術可行。
• 測試者：確保範例可用於驗收測試。
• 專案經理：協調每批的進度，確保按時完成。

(4) 工具

• 文件工具：Confluence、Jira，記錄每批範例。
• 協作工具：Miro（討論）、Google Docs（即時編輯）。
• 規格工具：Cucumber（Gherkin）、Excel。
• 測試工具：Selenium、Cucumber，支援自動化測試。

(5) 注意事項

• 批次間一致性：每批的範例格式要統一，否則後期整合會有問題。
• 累積知識：記錄每批的經驗教訓，後續批次可以寫出更好的範例。
• 時間管理：每批的時間有限，工作坊要聚焦，避免拖延。
• 需求變更：如果某批發現前期範例有問題，需更新並通知相關團隊。
• 跨批依賴：有些功能可能跨批次相關（例如：支付和結帳），要提前規劃範例。

(6) 故事案例
你是一家電商公司的專案經理，要開發一個購物平台，總共 100 個功能，分成 10 批，每批 10 個功能。第一批是「購物車功能」，包含「添加商品」「移除商品」等 10 個功能。

你組織了一個 2 天的工作坊，找來產品負責人（小美）、業務分析師（小明）、開發者（小強）和測試者（小花）。針對「添加商品」，大家寫了範例：

Given：購物車是空的，用戶選擇 1 個 500 元的商品；
When：點擊「加入購物車」；
Then：購物車顯示 1 個商品，總額 500 元。

其他範例包括：商品缺貨、添加多個商品等。

小明把範例整理成一個 Jira ticket，包含一個表格。小美確認後，團隊進入設計和開發。測試階段，小花用範例驗證，發現「缺貨商品」沒正確顯示錯誤訊息，於是小強修正。首批功能上線後，你檢討發現範例寫得太簡單，於是第二批（結帳功能）時要求更詳細的邊界條件，例如「網路斷線時的處理」。最終，10 批順利完成，平台功能完整且穩定。

9.3 不定期需求開發

這種情境下，需求不是一次或分批給定的，而是隨時有新需求進來，每次可能 1-10 個功能，量不固定。瀑布式流程還是適用，但每次需求的規模較小，實例化需求幫忙快速澄清需求，保持靈活性。

(1) 方式

• 即時工作坊：每次新需求進來，快速召集小規模會議，討論範例。
• 動態文件：範例記錄在一個持續更新的規格庫，方便隨時查閱。
• 快速迭代：需求量小，範例可以很快寫好並進入下個階段。
• 標準化流程：雖然需求不定期，Spec by Example 的格式和流程要保持一致。

(2) 步驟
A. 需求收集：

• 產品負責人提交新需求（例如：3 個功能），可能是臨時的業務需求。
• 業務分析師快速整理，確認需求範圍。

B. 小型工作坊：

• 召集產品負責人、業務分析師、開發者、測試者，開 1-2 小時的會議。
• 針對每個功能，寫出 Given-When-Then 格式的範例。
• 例如，對於「忘記密碼」功能：

Given：用戶輸入註冊的 email；
When：點擊「重設密碼」；
Then：系統發送重設連結。

C. 精煉範例：

• 確保範例涵蓋主要場景（正常、邊界、異常），但因規模小，數量較少。
• 產品負責人快速審查，確認無誤。

D. 文件化與傳遞：

• 把範例記錄在 Confluence 或 Jira，加入現有的規格庫。
• 設計、開發、測試階段參考這些範例。

E. 驗證與持續更新：

• 測試階段用範例驗證功能，完成後部署。
• 隨著新需求進來，持續更新規格庫，確保所有範例一致。

(3) 參與角色

• 產品負責人：提供不定期需求，審查範例。
• 業務分析師：整理需求，主持小型工作坊。
• 開發者：參與討論，確認範例可行。
• 測試者：確保範例可用於測試。
• 專案經理：協調臨時會議，管理規格庫。

(4) 工具

• 文件工具：Confluence、Jira，動態更新規格庫。
• 協作工具：Google Docs（快速編輯）、Zoom（臨時會議）。
• 規格工具：Cucumber（Gherkin）、Excel。
• 測試工具：Selenium、Cucumber。

(5) 注意事項

• 快速反應：需求隨時進來，工作坊要即時組織，否則會拖延。
• 規格庫管理：範例數量會隨時間增加，要定期整理，防止混亂。
• 一致性：不同需求的範例格式要統一，否則後期維護困難。
• 資源分配：不定期需求可能打斷其他工作，專案經理要平衡資源。
• 範圍控制：小規模需求容易擴大，工作坊要聚焦在當前功能。

(6) 故事案例
你是一家旅遊平台的專案經理，負責維護一個預訂系統。需求不定期進來，像是這週產品負責人（小美）說要加「取消訂單」功能（共 3 個子功能）。你立刻組織了一個 2 小時的線上會議，找來小美、業務分析師（小明）、開發者（小強）和測試者（小花）。

針對「取消訂單」，你們寫了範例：
Given：用戶有一個未出發的訂單，價值 2000 元；
When：點擊「取消訂單」；
Then：訂單取消，退款 2000 元到原支付帳戶。

其他範例包括：訂單已出發（不可取消）、退款失敗等。

小明把範例記錄在 Jira，加入現有的規格庫。小美確認後，團隊快速進入設計和開發。測試階段，小花發現退款失敗時沒顯示錯誤訊息，於是小強修正。功能上線後，小美又提出新需求（「訂單評價」功能），你重複同樣流程，持續更新規格庫。最終，系統功能逐步完善，規格庫也成為團隊的寶貴資產。

Spec by Example 在瀑布式流程中，能讓需求更具體，減少誤解。根據不同情境：

• 大批量開發適合集中式、大規模的工作坊，需嚴格管理一致性和全面性。
• 分批開發適合小規模、迭代式的工作坊，需注意批次間的連貫性。
• 不定期需求需要快速反應和動態規格庫，保持靈活但一致。

每個情境都靠跨部門協作、簡單範例和結構化文件來成功。希望這三個案例讓你對 Spec by Example 的應用更清楚！